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(54) System for digitaliy signing a document 

(57) The preferred embodiment of the invention 
comprises a computer system which employs a trusted 
display processor (260). which has a trusted processor 
(300) and trusted memory (305. 315. 335. 345) physi- 
cally and functionally distinct from the processor and 
mefnory of the computer system. The tmsted display 
processor (260) is immune to unauthorised modification 
or inspection of internal data It is physical to prevent 
forgery, tamper-resistant to prevent counterfeit'mg. and 



has crypto functions (340) to securely communicate at 
a distance. The trusted display processor (260) interacts 
with a user's'smartcard (1 22) in order to extract and dis- 
play a trusted image, or seal (1000). generate a digital 
signature of the bitmap of a document image and control 
the vkJeo menrxxy (315) so that other processes of the 
computer system cannot subvert the image during the 
signing process. Ttie user interacts wHh the trusted dis- 
play processor via a tmsted switch (135). 
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Description 

Technical Fieid 

5 [0001] The present invention relates to apparatus and nrtethods for digitally signing image data, and in particular 
documents, in a manner which provides a high level of confidence to a signing party that the document they thinic they 
are signing is in fact the document they are signing. ' 

Background Art 

[0002] Conventional prior art mass rnarkex computing platfonns include the well-known personal computer (PC) and 
connpeting products such as the Apple Macintosh^, and a proliferation of known patrrmop and laptop personal com- 
puters. Generally, markets for such machines fall into two categories, these being domestic or consumer, and corporate. 
A general requirement for a computing platform for domestic a consumer use is a relatively high processing power, 
Internet access features, and multi-media features for handling computer games. For this type of computing platlorm. 
the Mk:rosoft Windows 95 and 98 operating system products and Intel processors, so-called WinTel platforms, dom- 
inate the market. 

[0003] On the other hand, for business use. there are a plethora of available proprietary computer platform solutions 
available aimed at organizatbns ranging from small businesses to multi-national organizations. In many of these ap- 
so plicalions. a server platform provkJes centralized data storage, and appl»atk>n functionalliy for a plurality d client 
statk)ns. For business use. other key criteria are reliability, remote access, networking features, and security features. 
For such platforms, the Mcrosoft Windows NT 4.0™ operating system is common, as well as the UNIX and. more 
recently, the Linux operating systems. 

[0004] Windows-type operating systems atk>w a user to run separate applicatbns in separate windows, and provkle 
^ a so-called WIMP (windows, icons, menus and pointers) interface, whereby a user typically interacts with applcations 
using a keyboard to enter data and a mouse to select options and control applications via dialog boxes and drop-down 
(or putl-up) menus. 

[0005] With the increase in commercial activity transacted over the Internet, known as 'e-commerce*. there has been 
much interest in the prior art on enabling data transactksns between computing platforms, over the Internet. In partbuiar. 

so it is perceived to be important for users to be able to enter into binding contracts over the Internet, without the need 
for the current standard hand-signed paper contract. However, because of the potential for fraud and manipuiatkxi of 
electronk: data, in such proposals, fully automated transacttons with distant unkrKywn parties on a wkte-spread scale 
as required for a fully transparent and effk:ient market place have so far been held back. The fundamental issue is one 
of trust between users and their computer platforms, and between interacting computer platforms, for the making of 

3S such transactions. 

[0006] There have been several prior art schemes whk:h are aimed at irx:reasing the security and trustworthiness 
of computer platforms. Predominantly, these rely upon adding in security features at the applk:ation level, that Is to say 
the security features are not inherently embedded in the kemel of operating systems, and are not built In to the funda- 
mental hardware components of the computing platform. Portable computer devices have already appeared on the 

40 market which include a smartcard. which contains data specific to a user, which is ir^ut into a smartcard reader on the 
computer. Presently, such smartcards are at the level of being add-on extras to conventional personal computers, and 
in some cases are integrated into a casing of a known computer. Although these prior art schemes go some way to 
improving the security of computer platforms, the levels of security and trustworthiness gained by prtor art schemes 
may be consklered insufficient to enable widespread applicatton of automated transactions between computer plat- 

45 f omns. Before businesses expose signifk»nt value transactions to electronic commerce on a wkJespread scale, they 
will require greater confidence in the trustworthiness of the underlying technotogy. 

[0007] In the applicant's co-pending patent appltoations Trusted Computing Platfomy 99301100.6. filed at tfie Eu- 
ropean Patent Office on i 5 February 1 999 and 'Computing Apparatus and Methods of Operating Computing Apparatus* 
9905056.9, filed at the UK Patent Offce on 5 March 1999. the entire contents of which are incorporated herein by 
so reference, there is disclosed a concept of a trusted computing platfonm' comprising a computing platform whk:h has 
a trusted component* in the form of a built-in hardware component. Two computing entities each provisbned with such 
a trusted component may interact with each other with a high degree of trusf . That is to say, where the first and second 
computing entities interact with each other the security of the interaction is enhanced compared to the case where no 
trusted component is present, becauee: 

ss 

• A user of a computing entity has higher confidence in the integrity and security of his own computer entity and in 
the integrity and security of the computer entity bek)ngino to the other party: 
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. Each entity is <x)nfidenl that the other entrty is in laQi the ^^^^ 

. Where one or both of the entities represent a party to a transaction: e.g. a data transfer transaction, because of 
the In-built trusted component, third party entities interacting with the entity have a high degree of confidence that 
5 the entity does in fact represent such a party: 

• The trusted component Increases the inherent security of the entity itself, through verification and monitoring proc- 
esses implemented by the trusted component; and 

10 • The computer entity is more likely to behave in the way ft is expected to behave. 

10008] As has been indicated above, the conventional method of signing a document is to physically write a signature 
on the medium (usually paper) upon which an image of a document is reproduced. This method has the advantages 
that it is clear what is being signed, and the signed image is proof of what was signed. However, it does not meet the 

IS needs of e-commerce. ^ ^ 

[0009] Nowadays it is also possible to digitally sign a document, using a conventional computer platform and standard 
encryption techniques. In conventional computer pbtfomrts. however, the present inventors have appreciated that the 
electronic rendition of a document which is digitally signed Is typically not the same rendition of the document that is 
visible to the user. It is therefore possible for a user to unintentionally sign data that is different from that which he • 

20 intended to sign. Conversely, it is also possible lor a user to intentionally sign data and later fraudulently claim thai ihe 
signed data does not correspond to that displayed to him by the computer' platform. Such problems would stQI be the 
present, even if a toisted platfomi, as described above, were used. 

[001 0] Conventional electronic methods of signing are well known to those skilled in the art. Essenti^ly, digital data 
is compressed into a digest for example by the use of a hash functwn. Then that digest is encrypted by the use of 

ss some encryption method that has been initialised by a secret key (or simply a 'socrof ). This is nomnally dono on a 
computer platform, such as a PC. One implementation Is to sign data using a private encryption key hefcJ secret on a 
user's smartcard. which is plugged into a smartcard reader attached to the computer platfomi. In the specific case of 
a textual document, the digital data may be the file produced by a word propessor applicatton. such as Microsoft's 
Notepad. Wordpad. or Wbrd. As usual, the act of signing implies that the signer accepts some legal responsibility for 

30 the meaning of the data that was signed. 

[0011] Hashfunctkxis are well-known In the prior art andcomprise one way functions which are capable of generating 
a relatively small output data from a relatively large quantity of input data, where a small change in the input data results 
in a significant change in the output data. Thus, a data file to whfch is applied a hash function results in a first digest 
data (the output of the hash function). A small change e.g. a single bit of data in the original data file will result in a 

3S significantly different output when the hash f unclkxi is reapplied to the modified data file. Thus, a data file compnsing 
megabytes of data may be input into the hash functon and result in a digital output of the order of 128 to 160 bits 
length, as the resultant digest data. Having a relatively small amount of digest data generated from a data file stored 
in the rose wed directory Is an advantage, since it takes up less memory space and less processing power in the trusted 
component 

40 [001 2] During known signing processes, a user will typfcally Interpret a document as it has been rendered on the 
computer's monrtor at nonnal magnification and resolution. In existing applications, the user's smartcard signs data In 
a format that is the representatkxi of the document by the application used to create and/or manipulate the document. 
The present inventors believe, however, that there is potential for software to send data to the smartcard that has a 
different meaning from that understood by the user when viewing the screen. This possibility may be sufttelent reason 

-«5 to introduce doubt into the validity of conventtonal methods of digitally signing electronk: represeniatkxis of documents 
that are to be interpreted by people. 

Disclosure ol the Invention 

&> [001 3] The invention consists of systenv» and methods to improve confidence in digitally signed documents that are 
to be interpreted by people. They necessarily involve the reliable display ol data, whrch can be used for other purposes. 
[0014] In accordance with a first aspect, the present inventk>n provides a data processing systern arranged to gen- 
erate a digital signature representative of a document the data processing system comprising: 

iS main memory means for storing a document to be digitally signed; 

main processing means for executing at least one applk^tfon process comprising means to generate graphcs 
signals for displaying the document; 

means for generating a request signal for the document to be signed; 
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a display system comprising: 

mJ^ g JJe'S digHal inag. data representaUve of me document on the basis of the graphk* signals and 

a trusted component comprising independent processing means operable, .n response to rece^it of the request 
signal for generating a digilal signature f epresenlative of the digital image data. 
■o rnoisi Assuch the diqital signature Is generated on the basis d the data used to display the documwt to a 
S S ^prS;rrd eSimru.thetL.edcom^^^^ 

« orocess write access to at least the portion of the frame buffer memo^ contaning the digital tnage date of 

ELnSSsSrSMn^Cdg^llmagedata^ 

aT^rd"^. sS Ire. ConLientv. the removable toKen Is an appicpriateV P«.g«mmed smart- 
en in oreferredembodimerts the trusted component comprises means for acquiring andtor generally 

,0 KJte'aSm^^nsT^^trolllngthedtaptey^^^^^^ 

^ta This provides Visual feedback to a user thalthe trusted compooert is m control of the operatna 

ISr^eStTh^tLtedcon^aentcompr 

JflSr1inedcomponemprc.e,ablyfurthercomprisosme^s.orconU^^^^^^ 
^'7n"^lerrede„*odiments.thedataprocessingsystemfur.herco^^^ 

can respond lomessages hasecurefashion. The tnisled input means may compnse a switch connected lothe trusted 

30 component via a secure communications channel. .H..»i«.*h^!natinnnfneafis 

(0023) inpreferredembodiments.thetmstedcomponentandthesecuretokenenactamutualauthenticatonpTO 



SO 



l^^nSiiTSSSZts. the trusted component fomis an imegml part of the displ^ 

ss ;S:S,'S:^^3h^««mebunermemo.y.suchmatthemain^^^ 
frame butter memory indirectly through functions of the tmsted component. 

(S^rifSttie irustil component further comprises means for generating data summar^ing a digttal s^na- 

iSSg'^Saspectsandembodimentsolthelmrenllonwillbecomeappar^U^ 
40 and drawings. 



Brief E>escriptiQn oi me urawngs 

[0027] Embodiments of the present im«ntion will now be descrbed m deteil with reference to the accompanying 
drawings, (X which: 

Figure 1 is a diagram which lUustiates a computer system suitable for operating In accordance with the prefened 

in accordance with the preferred embodiment of the present invention; 

Fme A is a diagram which Illustrates a ha«lware architecture of a smart card proceesng engine suitable for 
opeiatfig in accordance with the preferred embodiment ol the present rwention: , « ia«i«i disolav 

?W 5 is a diagram wt,ich illustmtes a luncllonal archRecture of a host computer »,ch^ng ^ ^^^^^ 
pressor and a smart card .uitabl. lor operating in accordance with the preferred embod»r,ent ol the p^senl 

Sure'eUftowdiagiamwhichillustratesthestepsimwIvedh 
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Figure 7 is diagram which illustrates the sequence of messages between he trusted display processor and the 
smart card in order to recover seal image data from the smart card; 

Figure 8 is diagram which illustrates the sequence of messages between tKe trusted display processor and the 
smart card in order to generate a signature of a document image; 
5 Figure 9 is diagram which illustrates the sequence of messages between the tmsted display processor and the 
smart card in order to generate a signature of a summary of the document Image signing process; 
Figure 10a is a diagram which illustrates an exemplary trusted image; 

Figures 10b to lOd are diagrams which illustrate the visual steps in signing a document Image; and 
Figures lOe to lOg are diagrams which illustrate alternative ways of highlighting the image of a document to be 
10 . signed. 

Best Mode For Carrying Out the Invention. & Industrial ApplicabiliV 

[0028] The preferred embodiment utilises a trusted component that tnos\ conveniently uses some of the character- 
is istics of the Irusted component' described in the applicant's co-pending European patent application number 
99301100.6. In that application, the trusted component is a hardware device, comprising a processor programmed to 
measure an integrity metric of its host computer, compare it with a true value of the integrity metric and communicate 
the integrity (or otherwise) of the host computer to users or other host computers. The significant similarities between 
that irusted component and the tmsted component in the preferred embodiment herein are: 

20 

that they both use cryptographic processes but pre^f erably do not provide an external interface to those crypto- 
graphic processes; 

that they are both tampe r-resistant or tamper-detecting, so that their operation cannot be subverted, at least without 
the knowledge of the legitimate user; and 
25 that thoy both preferably consist of one physical hardware component that is both physically and functionally in- 
dependent of the host computer on which it resides. 

[0029] Such independence is achieved by the trusted component having its own processing capability and memory 
[0030] Techniques relevant to tamper-resistance are well known to those skilled in the art of security, as described 

30 in the applicant's co-pending appricatkxi. These techniques include methods for fabrfcating components to resist tam- 
pering, methods for detecting tamperrig. and nnethods for eliminating data when tannpering is detected. It will be ap- 
preciated that, although tamper-proofing is a most desirable feature of the present invention, it does not enter into the 
nomnal operation of the inventkxi and. as such, is beyond the scope of the present descriptkm. 
[0031] In this description, the term Irusted*. when used in relalton to a physk:al or bgk:al conrvxirient or an operation 

3$ or process, implies that the behaviour thereof is predictable under substantially any operating cbnditkxi and highly 
resistant to interference or subversion by external agents, such as subversive application software, viruses or physical 
interterence. 

[0032] The temi "host computer' as used herein refers to a data processing apparatus having at least one data 
processor, at least one form of data storage and some form of communications capability for interacting with external 
40 entities, such as peripheral devices, users and/or other conriputers locally or via the Internet. The term "host computer 
system' in addition to the host conrtputer itself includes standard external devices, such as a keyboard, mouse and 
VDU, that attach to the host computer. 

[0033] The terni 'document', as used herein, includes any set of data that can be visualised using a host computer 
system. Commonly a document will be a textual document, such as a contract However, a document may comprise 
45 graphics, or pictures, instead of, or as well as. text. In general, a docunrient may comprise a single page or multiple 
pages. 

[0034] The term 'pixmap*. as used herein, is used broadly to encompass data defining either nxmochrome or cotour 
(or greyscale) images. Whereas the term 'bitmap' may be associated with a monochrome image only, for example 
where a single bit is set to one or zero depending on whether a pixel is 'on' or 'off. 'pixmap' Is a more general temn. 
50 whwh encompasses both nx)nochrome and cok>ur images, where cobur images may require up to 24 bits or more to 
define the hue. saturation and intensity of a single pixel. 

[0035] As vyill become apparent, the tmsted component according to the preferred embodiment herein provktes a 
secure user interface and. in particular, controls at least some of the display functkmality of its host computer. The 
trusted component herein may or may not also acquire integrity metres according to the tmsted component in appli- 
es cant's co-pending patent appfcation, although such acquisitkxi of integrity metrk» will not be conskJered herein. 

[0036] In essence, the preferred embodiment enables a user to digitally sign a document stored on a host computer 
using the private key of the user's smartcard. or other form of secure token such as a cryptographic co-processor. The 
signing is enacted by a trusted display processor (i.e. the tmsted coniponent) of the host computer under conditbns 
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♦u ^^r«,i.hflhifih level dcwnfWence that the ckxumentbei^^ 

the tost ^'^^^^"^irri^^ or a device with similar properties is associated with video 

[0037] More particularty. the ^^^^'T^ ^ata can be manipulated by standard host computer 
data at a stage in the v.deo P^^^^^^^;.^;^^^ ^l^Jsce without interference or subver- 

^iSJS ta t^e ^T?is is used to unambiguously identify the Image (pixmap) that a user b signing. A side^ert 
^^ZtsZ^TJ^P^ felU display any of its data on the display surface. «clud«9. for 

wssmmmm 



30 



35 



40 



[004q all of which are mounted on a motherboard 

essor.connec,ed,omahn^.vJ.Wj«^^^^ ^ ^ ^ , pC. 

215 ol the host ^j;^"**;^*^ 

(Peripheral Component Interconnect) bnoge ^^Joa '^^1°^^- aririra«B and data DOitions. which wiU not be 
» I AN /local area network) adaptor 250 for connecting the host computer 100 to a LAN l Z5, via wnicn ^^"^'^J' 

functions tor generating digital signatures and pmvidingatmsted user interface 

thAfundlons could alternatively be physically splH Wo tvro or more separate physical components. However, nwm oe 

JS,S^ore!it^follng'^^ 

sf a most elegant and cooweniontsolulion. 

[0044] According to Figure 3. the trusted display processor 260 comprises. 



a micrecontroHer 300; 
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non-volatile memofy 305. for example flash mernory. containing respective control program instructions (i.e. 
firmware) lor controlling the operation of the microcontroller 300 (alternatively, the trusted display processor 260 
could be emlKxJied in an ASIC, which would typically provide greater pertomiance arwl cost efficiency in mass 
production, but would generally be nriore expensive to develop arid less flexible): 
5 an interlace 310 for connecting the trusted display processor 260 to the PCI bus for receiving image data (l.e. 

graphics primitives) from the CPU 200 and also trusted image data from the smartcard 122, as will be described; 
frame buffer memory 315, which comprises sufficient VRAM (video RAM) in which to store at least one full image 
frame (a typical frame buffer memory 31 5 is 1 -2 Mbytes in size, for screen resolutions of 1280x768 supporting up 
to 16.7 million colours); 

10 a video DAC (digital to analogue converter) 320 for converting pixmap data Into analogue signals for driving the 
(analogue) VDU 1 05, which connects to the video bAC 320 via a video interface 325; 
, an interface 330 for receiving signals directly from the trusted switch 1 35; 
volatile memory 335, for example DRAM (dynamic RAM) or more expensive SRAM (static RAM), for storing state 
information, particularly received cryptographic l^eys, and for providing a work area for the microcontroller 300; 

»5 a cryptographic processor 340. comprising hardware cryptographic accelerators andAor software, arranged to pro- 
vide the trusted display processor 260 with a cryptographic identity and to provide authenticity, integrity and con- 
fidentiality, guard against replay attacks, make digital signatures, and use digital certificates, as will t>e described 
in more detail bek>w; and 

non-volatile memory 345: for example flash memory, for storing an identifier l^p of the tmsled display processor 
20 260 (lor example a sinple text string name), a private key Sqp of the trusted display processor 260, a certiHcale 
Certop signed and provided by a trusted third party certiffcation agentiy, sucTi as VeriSign Inc., whteh binds the 
trusted display processor 260 with a signature public-private key pair and a confidentiality public-private key pair 
and includes the corresponding publk; keys of the trusted display processor 260. 

2S [0046] A certificate typically contains such information, but not the publk: key ol the CA. That publw key is typk:any 
made available using a 'Public Key Infrastructure' (PKI). Operation of a PKI is well known to those skilled iri the art of 
security. 

[0046] The certificate Certpp is used to supply the public key of the tnisted display processor 260 to third parties in 
such a way that third parties are conf ident of the source ol the publk; key and that the public key is a part of a vaUd 
30 public-private key pair. As such, it is unnecessary for a third party to have prior knowledge of. or to need to acquire, 
the publk: key of the trusted display processor 260. 

[0047] The tnjsted display processor 260 lends its identity and trusted processes to the host computer and the trusted 
display processor has those properties by virtue of its tamper-resistance, reslstarice to forgery, and resistance to coun^ 
terfeiting. Only selected entities with appropriate authentication mechanisms are able to influence the processes run- 

3S ning inside the trusted display processor 260. Neither an ordinary user of the host computer, nor any ordinary user or 
any ordinary entity connected via a network to the host computer may access or interfere with the processes running 
InskJe the trusted display processor 260. The trusted display processor 260 has the property of being ■invk)late'. 
[0048] Originally, the trusted display processor 260 is initialised with its kientity. private key and certificate by secure 
communteatk>n with the trusted display processor 260 after It is installed onto the mothertx>ard of the host computer 

-«o 100. The method of writing the certifk^te to the twsted display processor 260 is analogous to the method used to 
initialise smartcards by writing private keys thereto. The secure communications is supported by a 'master key*, known 
only to the trusted third party (and to the manufacturer of the host computer 100). that is written to the trusted display 
processor 260 during manufacture, and used to enable the writing of data to the trusted display processor 260. Thus, 
writing ol data to the trusted display processor 260 without knowledge ol the master key is not possible. 
. ^5 [0049] It will be apparent from Figure 3 that the frame buffer memory 315 is only accessible by the trusted display 
processor 260 Itself, and not by the CPU 200. This is an important feature of the preferred embbdlntent. since it is 
imperative that the CPU 200. or. more importantly, subversive applteation programs or viruses, cannot modify the 
pixmap during a trusted operation. Of course, K would be feasible to provkte the same level of security even If the CPU 
200 could directly access the frame buffer memory 315, as tong as the trusted display processor 260 were arranged 

so to have ultimate control over when the CPU 200 couM access the frame buffer memory 315. ObvkHisly, this latter 
scheme wouM be more difficult to implement. 

[0050] A typical process by which graphics primitives are generated by a host computer 100 will how be described 
by way of background. Initially, an application program, which wishes to display a particular image, makes an appro- 
priate call, via a graphical API (applicatk>n programming interface), to the operating system. An API typically provkies 
ss a standard interlace for an application program to access specific underlying display functions, such as provkJed by 
Windows hTf'^, for the purposes of displaying an \mage. The API call causes the operating system to make respective 
graphics driver library routine calls, which result in the generatton of graph cs primitives specific to a display processor; 
whfch in this case is the trusted display processor 260. These graphics primitives are finally passed by the CPU. 200 



7 



SNSOOCtD <EP 10S69egiAl_l_> 



EP105598&A1 
functions topf(x»88 me receh«d'g»aphics primitives, spec^^^^ 

to display the required image on the screen, 
interaction with the cwtographic proce^ aid^^ 

10053] The trusted display processor 260 forms a part or '"^ J^,^ bvaoplication programs and 

SS'^.sa.readv^tl«^..-P-ente.*o«r^r^ 

260 and the user's smartcard 122. The proc^.r^ "TL JL^nSSisaproces8or4^ 
prelerredemtxx.«,entisyiustratedinF«ure4.Thepr«es^ ^ ,^ 

« encryption and decryption fun^-^to ^^^^f^' ^^1^^,^^ which^ a b«?t-ln operat^ 
•Isewhere. In the present ^n^odiment me pr<xesso^j*w 8 a through ISO 

remand is arranged to commun^^ew^ 

7816-3. 4, T=0. T=1 and T=14 ^"^^J*^,^^^^"^^ key Ssc. "sed for digitally signing data, and a 
memory, containing an ident*.er l8c dtr»8n«rtcart^^^ 

certificate Certsc- P-™^ "y a trusted third party '^^^'^"f^^^^r,^ i„ nature to the certificate Certop 
Key pain* and includes the corre^dmg publc keys 

of thetrusteddfeplay processor 260^Further. 'l^^^^^^^Z^i^ hKJIcate to the user thai a process is 
Which can be represented '"^^^^^ ♦^^Sfbe JSS^ 

operating securely with the user's smartrard. as wrtMbe ^ by the user as a unique IdentHier. for 

Sta SEAL. ^ the .«j. cJ«,^^o^^^ 

example an image of the user hmseB. "^""^^ ^ . ^lortng state Wormation (such as recewod l^eys) 
400 also has access to volatile memory 430. Lnple electrical contacts, lor commu- 

and providing a v^orlong area for the processor 400, and an ntertace 4W. wr 

nicating with a smart card reader. . , . ».^«te«imemiMv if stored as pixmaps. This inay be a distinct 

lOOSq seal »nages can consume retetwely ^'Sf^^^^J^SS^a s^S^^ iSwhere memiy capacity is 
disadvantage in circumstances wh«« the .n^^^^^ 

relatively nmlted. The memory '^''^T^'^^^y^^ressea by the trusted display processor 280: a 

ioage could comprise: a T^^St^ f rew^iS^^ic generated by the trusted display processor 

thumbH^iMmage thm ton^the pnmrt|ve eten^^ 

260; a naturally compressed image, such as a set « "t^^T; ,, gbova In any of these alternatives, 

display processor 260 as a single large .mage, or "^^^f" " "^,^^^60 to decrypt the data before 
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sented in ovals, and the •permanent' data (including th^ documen! image for the duration of the signing process), oh 
which the functions act. are shown in boxes. Dynamic data, such as state data or received cryptographs keys are not 
illustrated, purely for reasons of clarity. Arrows between ovals and between ovate and boxes represent respective 
logical communications paths. 

s [0057] In accordance wtth Figure 5. the host computer 100 includes: an application process 500. for example a 
wordprccessor process, which requests the signing of a document: document data 505; an operating system process 
510; an API 511 process for receiving display calls from the application process 500; a keyboard process 513 for 
providing input from the keyboard 110 to the application process 500; a mouse process 514 for provkJIng input from 
the mouse 115 to the application process 500; and a graphk» primitives process 515 for generating graphfcs primitives 

10 on the basis of calls received from the application process via the API 511 process. The API process 511 . the keyboard 
process 51 3, the mouse process 51 4 and the graphics primitives process 515 are buikj on top of the operating system 
process 510 and communcate wrth the appfcatbn process via the operating system process 510, 
[0058] The remaining functions of the host computer 1 00 are those provided by the trusted display processor 260. 
These functions are: a control process 520 for co-ordinating ail the operattons of the trusted display processor 260, 

IS and for receiving graphics primitives from the graphics primitives process and signature requests f^ 

process 500; a summary process 522 for generating a signed summary representative of a docunnent signing procedure 
in response to a request from the control process 520; a signature request process 523 for acquiring a digital signature 
of the pixmap from the smartcard 122; a seal process 524 for retrieving seal data 540 from the smartcard 122; a 
smartcard process 525 for interacting with the smartcard 122 in order to enact challenge/response and data signing 

20 tasks required by the summary process 522. the signature request process 523 and the seal process 524; a read 
pixmap process 526 for reading stored pixmap data 531 and passing it to the signature request process 523 when 
requested to do so by the signature request process 523; a generate pixmap process 527 for generating the pixmap 
data 531 on the basis of graphics primitives and seal image data received from the control process 520; a screen 
refresh process 528 for reading the pixmap data, converting it into anatogue signals and transmitting the signate to the 

2S VDU 105; and a trusted switch process 529 for monitoring whether the trusted switch 135 has been activated by the 
user. The smartcard process 525 has access to the trusted display processor's identity data bp. private key S^p data 
and certifk»te Certop data 530. In practice, the smart card and the trusted dteplay processor interact with one another 
via standard operating system calls. 

[0059] The smartcard 1 22 has: seal data 540; a display processor process 542 for interacting with the trusted display 
30 processor 260 to enact challenge/response and data signing tasks; smartcard dentlty data Isc. smartcard private key 
data Ssc and smartcard certificate data Certec 543. • 

[0060] A prelen-ed process for signing a document using the arrangement shown In Rgures 1 to 5 will now bei de- 
scribed with reference to the flow diagram in Figure 6. 

[0061] Initially, in step 600. the user controls the appltoation process 500 to inHiate a 'signature request' for digitally 
Jts signing a document. The applfcatfon process 500 may be realised as a dedicated software program or may be an 
additton. for example a macro, to a standard word processing package such as Microsoft's Word, in either case, neither 
the signature request nor the application process 600 need to be secure. When the user initiates the signature request, 
he also specifies the document to be signed, if it is not one which is already filling the whole screen. For example, the 
document may be dteplayed across a part of the full screen area or in a partk:ular window Selectkxi of a partcular 
'to area on screen is a simple task, which may be achieved in several ways (using a WIMP environmerit), for example by 
drawing a user-defined box bounding the area or by simply specifying co-ordinates. 

[0062] Next, in step 602. the applicatkx) process 500 calls the control process 520 to sign the Image that Is being 
displayed (within a definedarea or window) on the screen; the control process 520 receives the call. In parallel, although 
it is not shown, the control process 520 receives any graphtes primitives from the graphics primitives process and 

-«5 fon^rds them onto the generate pixmap process 527. The call from the applicatkx) process 500 to sign a document 
includes the co-ordinates (a,b.c,d) Of the edges of the document. Note that this sending of coordinates generally 
enables the signing of the entire surface of the screen, a corrtplete window, or of an arbitrary part of the screen. The 
application process 500 then waits for the control process 520 to retum the signature of the Image. 
[0063] In response to the signature request, in step 604, the control process 520 forces the image that is to be signed 

^ to be 'static' from the time of the request until the process has been completed. Herein, 'static* means that the document 
image cannot be modified other than by the trusted display processor 260. This is so that the user can be certain that 
what he sees is what he is signing at all times during the process. In the present embodiment, the control process 520 
achieves a 'statk;' display by 'holding-off, or not processing, any further graphtes primftives. In some situations, the 
graphfcs primitives process (or equivalent) may 'buffer* graphics primitives until the control process 520 is ready to 

*5 receive further graphics primitives. In other situations, graphics primitives for the image to be signed may simply be 
lost. Where the docunrwnt image fills the whole screen, making the image state is simply a case not processlrig any 
graphics primitives. However, where the image to be signed fonns only a subset, for example a window, of the full 
screen, the control process 520 needs to determine whether received graphk» primitives wouW affect the 'statk:* area. 
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and reject ones that would. As such, the pixmap of the static document image in the franne buffer memory 315 remains 
unchanged by any instructions from the graphics primitives process, or any other process executing on the CpU 200, 
while the document Image is static. 

[0064] Once the document image hajS been made static, in step 606. the control process 520 instructs the generate 
pixmap process 527. including in the call the coordinates (a,b.c,d) provided by the application process 500. to nrKxjiiy 
the pixmap to highlight the document to be signed/ as will be described in more detail below with reference to Figure 
10c. Then, in step 608, if a smartcard 122 is not already inserted ih the smartcard 122 reader 120. as detemiined by 
the smart card process 525. the control process 520 instructs the generate pixmap process to display a graphical 
message asking the user to Insert his smartcard 1 22. This message is accompanied by a ten second countdown timer 
COUNT If the countdown timer expires (i.e. reaches zero), as a result ol not receiving the smartcard 122, the control 
process cancels the signing operation in step 614 and returns an exception signal to the application process 500. In 
response, the application process 500 displays an appropriate user message in step 616. If the smartcard 122 is 
inserted in time, or is already present, then the process continues. 

[0065] Next. In step 616. the control process 520 calls the seal process 524. and the seal process 524 calls the 
smartcard process 525, to recover the seal data 540 from the smartcard 1 22. Optionally, the control process 520 caHs 
the generate pixmap pnxess 527 to display another message indicating to the user that recovery of the seal data 540 
is being attempted. In steps 618 and 620. the smartcard process 525 of the trusted display processor 260 and the 
display processor process 542 of the smartcard 122 interact using weU Itnown. 'challengefresponse' techniques to 
enact nrujtual authentication and pass the seal data 540 from the smartcard and bacli to the control process 520. The 
details of the mutual authentication procescf and passing of the seal data 540 will now be described with reference to 
Figure 7. 

[0066] According to Figure 7. the smartcard process 525 sends a request REQ1 to the smartcard 122 to return the 
seal data SEAL 540. The display processor process 542 generates a nonce R, and sends it in a challenge to the 
smartcard process 525. The smartcard process 525 generates a nonce and concatenates it with nonce R,. signs 
tho concatenation IIRg wfth its private key to produce a signature 8Sdp(Ri IIR2). and returns the concatenation R, HR^ 
the signature 8Sop(B| IIR2) and the certificate Certop back to the display processor process 542 of the enoartcard 1 22. 
The display processor process 542 extracts the pubIc key of the tnisted display processor 260 from the certifcate 
Certpp, and uses this to authenticate the nonce R, and the signature sSqp(R^IIF^) by comparison with the concate- 
nation R^ IIRg, to prove that the seal request came from the expected trusted display processor 260 and that the trusted 
display processor 260 is online. 

[0067] The nonces are used to protect the user from deception caused by replay of okl but genuine signatures <called 
a 'replay attack") by untrustworthy processes. 

[0066] The display processor process 542 of the smartcard 122 then concatenates Rg with its seal data SEAL 540. 
signs the concatenation RgllSEAL using its private key Sgc to produce a si^ature sSscCRg^SEAL), encrypts the seal 
data SEAL 640 using its private key Bsc to produce encrypted seal data 540 sSsc(SEAL), and sends nonce Rg, the 
encrypted seal data sSsc(SE AL), the signature sSsc(Fl2llSEAL) and the smartcard's certlfteate Certgc to the smartcard 
process 525 of the tnjsted display processor 260. The smartcard process 525 extracts the smartcard's pubto key from 
the certificate Certsc and uses this to verify nonce R2 and the signature 6Ssc(Ff2llSEAL). decrypt the seal data SEAL 
540 from the encrypted seal data 540 8S8o(SEAL) and. finally, return the seal data SEAL 540. via the seat prccese 
524. to the control process 520. 

[0069] Returning to Figure 6. in step 622. when the control process 520 receives the seal data SEAL 540, it forwards 
the data to the generate pbcmap process 527, and instmcts the generate pixmap process 527 to generate a seal image 
and use it to highlight the document to be signed, as will be described below with reference to Figure lOd. Then, in 
step 624, the control process 520 instructs the generate pixmap process 527 to display a message to the user asking 
whether they wish to continue with the signing operation. This message is accompanied by a ten second countdown 
timer COUNT If the countdown timer expires. In step 626, as a result of not receiving a response from the user, the 
control process cancels the signing operation. In step 628, and returns an exceptton signal to the applicatnn process 
500. In response^ the applicalion process 500 displays an appropriate user message in step 629. If, in step 630, the 
user responds positively by actuating the trusted switch 135 within the ten second time limit, the process continues. 
The authorisation to continue couti alternatively be supplied over an unreliable channel, rather than by using a trusted 
switch 135. or even using appropriate software routines, providing a reasonable level of authenticatkm is used. Alter- 
natively, n may be deckled that the nr>ere presence d an authentic smartcard may be sufTicient authorisation for the 
signing to occur. Such an alternatives are a matter of security policy. 

[0070] Next, in step 632, the control process 520 instructs the signature request process 523 to request the signing 
of the document image: the signature request process 523 calls the read pixmap process 526 to request return of a 
digest of the pixmap data of the document to be signed; and the read pixmap process 526 reads the respective pbcmap 
data, uses a hash algorithm to generate a digest Dpix of the pixmap data and returns the digest to the signature request 
process 523. Additionally, the read pixmap process 526 generates 'display format data' FD. which includes information 
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necessary to reconstruct the image Irom the pixmap data Into a text-based document at a later time (FD is not essential, 
since the document text may not need to be reconstructed), and returns this also to the signature request process 523. 
For example, the display format data FD may include the number of pixels on the screen surface and their distribution, 
such as '1 024 by 768', and the font type and size used for the text (H the document Is text-based) in the document (at 
5 least some of this information may instead, or In addition, be contained in a document 'summary', as wiU be described 
below). In steps 634 and 636. the signature request process 523 interacts with the display processor process 542 of 
the smartcard 122 using well-known challenge/response processes to generate an individual signature of the docu- 
ment, as will now be described in detail with reference to the flow diagram in Figure 8. 

[0071] According to Figure 8, the smartcard process 525 generates a request REQ2 for the smartcard 1 22 togenerate 
10 a signature of the digest Dp,x and display format data FD, The display processor process 642 of the smartcard 122 
responds by generating a nonce R3 and sending it to the smartcard process 525 with a challenge to return the digest 
Dpix and the display format data FD. The smartcard process 525 concatenates the digest Dp,x with the display fomwt 
data FD and nonce R3, and signs the concatenation DptxIlFDIIRa to produce a signature sSopCDppcllFDIIRa). The 
smartcard process 525 then sends the concatenation DpocUFDIIRa and its respective signature sSopCDpocllFOIIRa) to 
IS the display processor process 542 of the smartcard 122. The display processor process 542 uses the trusted display 
processors public Key (which it has already received in the seal data 640 exchange) to verify the trusted display 
processors signature sSopCDpixUFDllFlj) and nonce R3, to prove that the digest is the current image digest The display 
processor process 542 signs the digest of the pixmap Dp,x and the display formal data FD. using Its private Key. to 
produce two signatures sSsc(Dpix) and sSsc(FD) respectively. The display processor process 542 of the smartcard 
20 then returns the signed digest sSsc(Dpix) and signed display formal data sSsc(FD) lo the smartcard process 525 of 
the trusied display processor 260. The smartcard process 525 next verifies the digest Dpix and display format data 
FD. using the smartcard's public Key (which it already has as a result of the seal data 540 exchange), and verifies the 
smartcard's signature, to prove that the smartcard is still onBne. 

[0072] Returning to Figure 6. in step 638. the snrartcard process 525 of the trusted display processor 260 concate- 
8S natos the pixmap PIX. the snnartcartfs signed versions of the pixmap digest sSsc(Dp,x) and display fonmat data eSsc 
(FD) to form an Individual signature PIXIIsSsc(Dpix)lleSsc(FD) of the image, and relume it. via the signature request 
process 523. to the control process 520. which retums the individual signature to the application process 500, The 
application process 500 stores the individual signature, in step 640. and responds with a further call to the conliol 
process 520 to 'summarise the signing' operation in step 642. The purpose of a summary is to complete the signature. 
30 as wUI be described with reference to the flow diagram in Figure 9 and also the example summary below: 

1 TC-88503-00.01 

2 Access time: Thu 06-Mayl999, 11: 18 
35 3 Pages: 2 

4 ImageOl I 560 x 414 (187,190) (1024 x 768] 

+Gr4niin0LqS/twYuPdskyL4uk3no0w3LG2+f+/vzC4cKMPey/Lhba22ScvhK3CJ+apQxyikj 
cY5rTC563klovOPTBI/Iyq2PxRnic- 
1 -END SIGNATURE 

8 Image02 I 670 x 379 (201,228) 11024 x 768] 

9 BEGIN SIGNATURE- 
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9 """"BEG IN SIGNATURE*""""^ 

10 UVlw5Rgr5F0iAjvUW4GP28NKAA+tOy42uBbP78JeQ5w2OMIlafTYkSNtfn9VykYMPIfZLwM 
72ZV+4fFttuSg02I4n5iBkSEwtEj0z6ik/np6paq+01QQ2hhJCbq8OaX97Gnidg3AoBq4x+O 

hujinqkCJO+D26+x8kE2428YFXLPOI- 

11 END SIGNATURE 

12 Summary signature: 

so 13 BEGIN SIGNATURE ^ ^ tt o * 

14 ci2D2L2+4irsrci2cPjWFs£ltkyXrfHBUMlkAEyudaZcVxD3Xc2TN7txSazInM2deJL9qnA 

een2DW12GjplEESNkho2XjOkT5TYNv2ylYFk01SN+JVF09binc9GdYLo/hSOWyYG/U29Mzq2 
ktaTdTqY/gPhlGajrSJGqRros+we/c- 

15 END SIGNATURE 



BS 



[0073] In step 644. the control process 520 calls the summary process 522 to generate a summary message SUM 
containing the number of images <two in the example summary above) plus the individual signatures of the images 

(lines 6 and 10 of the example), a label identifying the trusted display device (line 1 in the example), the current time 
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and date (line 2 in the example) and a signed digest of the summary itself (line 14 in the example). For each image, 
the summaiy also includes ttfB size of the image in pixels (e.g. S60)t4l4 for image 1 ), the offset from the orjgin.ol the 
screen in pixels (e.g. 167,190 for jmage 1) and the display resolution in pixels (e.g. 1024x768 for image 1). 
[0074] The summary process 522 then generates a digest of the summary Dsum in step 646 and calls the smartcard 

5 process 525 of th e trusted display processor 260 to Interact with the smartcard 1 22 using challenge/response processes 
to generate a signature of the summary digest Dg^,^, as will now be described with reference to Figure 9. 
[0075] According to Figure 9. the smartcard process 525 generated a request RE03 for the smartcard 1 22 to generate 
a signature of the digest of the sumnnary D^um- The display processor process 542 of the smartcard generates a nonce 
R4 and sends it in a challenge to return the digest of the summary D^u^. The smartcard process 525 concatenates 

10 the digest Dsyi^i with nonce B4 and signs the concatenatbn Dgyn^llF^ to produce a signature sSDp(Dsuig|IIR4). The 
smartcard process 525 of the tmsted display processor 260 then sends the concatenation D^um''^4 respective 
signature 6SQp(Dsuiy|l^^4) ^^^^ display processor process 542. The display processor process 542 then verifies the 
trusted display processor^ signature and nonce R4, using the trusted display processor's public key (which It already 
has from the seal data 540 exchange), to prove that the summary Is the current summaiy. Next, the display processor 

IS process 542 signs the digest of the summary Dsum ^^'"9 '^^ private key and sends the signed digest ssJcCDsum) to 
the smartcard process 525. The smartcard process 525 of the trusted display processor 260 verifies the digest and 
verifies the smartcard's signature, using the smartcartfs public key, to prove that the smartcard is still online. 
[0076] Returning to Figure 6. in step 652, the smartcard process 525 retums the summary SUM concatenated with 
the signed digest of the summary sSsc(Dsum) ^^f^ concatenation SUMIIsSscCDsum))- via the summary process 

so 522, to the control process 520. and the control process 520 retums the summary SUMil8Ssc(D3UM) to the applicatkNi 
process 500. The applicatbn process 500 receives the summary in step 654. 

[0077] The individual signature and summary may be used by the applk:atbn process 500, or any other process 
running on the host computer 100 h various ways outskte the scope of this invention. Including as proof of contract, 
for storage or for transmission to other entities. 

25 [0078] Finally, in step 656, the control process 520 unfreezes the display, by recommencing receipt and processing 
of graphs primitives associated with the document image, and thereby in eRect returns control of the display back to 
the application process 500 or other application software. Alternatively, control may not be handed back to the appli- 
cation process 500 until the user actuates the trusted switch 1 35 again, typkally in response to another user message, 
whk^h, this time. woukJ not have a tinteout period. This wouM give the user more time to review the static document 

so image before returning the host computer to standard, non-trusted operation. 

[0079] In order to verify a signed document, both the individual signature PIXIIsSsc(Dpp()llsSsc{FD) and. the sum: 
mary SUMIIsSsc(C)8um) ^^st be verified. Such verification methods are well known to those skilled in the art of security 
For example, the signature on the digest of the pbcmap sSsc(Opix) verified using the publk: key of the user. whk:h 
is pubfoly available and preferably contained within a digital certificate Certsc supplied by a oertifeation authority The 

ss verified digest is then compared with a value obtained by recomputing the digest from the pixmap. where the digest is 
generated using a standard, well-known and defined hash function. If the match is exact, the signature has been 
verified. Other signatures, including the summary, are checked in the same way. 

[0080] A preferred metfiod of enabling a person to verify the wording of the signed document is to translate the 
piXfTiap back into an image. This requires an applk:atkxi, or indeed a trusted display processor 260, to load the pixmap 
40 data PIX into the frame buffer memory 31 5 of a respecthre host computer 1 00. This allows a person to view the document 
that the signer has signed. 

[0081] The stages of highlighting a document to be signed will now be described with reference to Figures 10a to lOd. 
[0082] In the prefen-ed embodiment, the seal data SEAL comprises a pixmap of a trusted image. For example, as 
shown in Figure 10a. the pixmap of the seal data 540 defines a 'smiley face' 1000. Figure 10b illustrates an image 

4S 1005 of an exemplary document Doci to be signed, in a window 101 Oof the screen (not shown). As a first highlighting 
step, after the image has been made static but before the seal data has been received, the trusted display processor 
260 highlights the docurrient to be signed by superimposing a frame 1020 around the document Image 1005, as Illus- 
trated In Figure lOc. Also, where a smartcard 122 is not present, a user message 1030 asking the user to insert his 
smartcard is displayed accompanied by a ten second countdown timer 1035. as also illustrated in Figure 10c. Next. 

so when the smiley face pixmap image is retrieved from the smartcard 1 22, the trusted display processor 260 embellishes 
the frame 1040 with multiple instances 1045. or a mosaic, of the smiley face, as shown in Figure lOd. In addition, as 
shown in Figure lOd, the tnisted display processor 260 generates a further user message 1050, accompanied by a 
ten second countdown timer 1055, asking the user whether they wish to proceed with the signing process. This em- 
bellished frame 1040 both indicates to the user that the correct static image area is being acted on and provides the 

s^ user with a high level of conf kJence that the tmsted display processor 260 is fully in control of the signing process: the 
presence of the user's own seal image provides confidence to the user that the message has come from the trusted 
display processor 260 rather than from some other (possibly subversive) software application or hardware devk:e. 
[0083] Figures lOe and lOg illustrate allematives to the Irame' visual effect illustrated h Figures 10c and lOd. In 
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Figure lOe. four single seal images 1060 are position^ at the comers of the static document image using the co- 
ordinates provided by the application process 500. to define the static image area. In Figure 10f, the static image is 
defined by modifying the background therec* to show a single seal image. In Figure lOg. the static image is defined 
by modHying the background thereof to show a mosaic of seal images. It is expected that the skilled reader will be able 
5 to think of other visual effects by which the statfc image may be higlhlighted in the light of the present descriptton. In 
addition, it may be desirable to Include further status messages during the signing operalton. for example •Retrieving 
seal data 540 now....'. 'Generating document signature now....', etc. 

[0084] It will be appreciated that the trusted display processor 260 needs to be able to display the seal image(s) and 
the messages in the correct places on screen. Clearly, the seal image and the message images are temporary, to the 

10 extent they appear during the signature process and disappear thereafter. There are well-known, standard display 
techniques for overlaying a first image with a second image, thereby obscuring a part of the first Image, then removing 
the second image and restorcig the portion of the first Image that had been obscured. Such technquefe are used as a 
matter of course in nomral windows environments, for example, where multiple windows may overlap one another. 
The trusted display processor 260 Is arranged to Implement one of more of these standard techniques for the purposes 

fs of superimposing the seal Image(s) and the message images over the standard display. 

[0085] In some scenartos. it may be that a document is too large to tit all at once onto the VDU 105 screen and still 
be easily read by a person. Obviously, for the present embodiment to be practfcal. it is essential that a user can very 
clearly read the document before signing It. Therefore, the document can be split Into multiple screen pages, each of 
whtoh needs to be signed and cryptographlcally chained to the signature of the previous page, as will now be descrilsed. 

20 [0086] First, the applcation process 500 causes the image ol the first page to be displayed and makes a call to the 
trusted display processor 260 for signing as before. When the tnisted display processor 260 returns the individual 
signature, instead of requesthg a summary, the applicatkxi process 500 instructs the tnisted display processor 260 
to display the image of the second page arrd sign the innage. Clearly, in this case, the trusted display processor 260 is 
arranged to support such a request by the application process 500. Only after alt images have been sigrwd and returned 

ss to the applcatton process 500 does the applicatkxi process 500 issue a request for a sumnnary. Then, tho sunwnary 
includes the number of images that were signed in this multi-page document, for example as illustrated in the two- 
page summary atsove. 

[0087] The first page in the multi-page document is signed in the same way as a single page, resulting in return of 
an individual signature. When subsequent images are presented for signing, however, the trusted display processor 

30 260 recognises that they are part of a multi-page document because no summary request was received after the 
previous signature request As a result, the trusted display processor 260 displays a different message, whfch requests 
permisston from the user to sign a continuation page. In response, the user who is signing a mufti-page document uses 
the same reliable permission channel as before (for example, the trusted switch 135) to confirm to the trusted display 
processor 260 that this page is associated with the previous page, and is also to be signed. When the tnisted display 

ss processor 260 receives this multi-page confirmation, ft concatenates the signature of the prevkxis signed page wim 
the pixmap of the current page, creates a digest of the concatenatkxi. and sends that to the smartcard for signing. This 
is instead of sending a digest of just the current pixmap. This process cryptographlcally thalns' a subsequent page to 
the prevteus page, so that pages cannot be rearranged without detectton. nor can intemiediate pages be inserted or 
deleted without detection. 

40 [0088] The validity of the first page may be checked in exactly the same way as a single page. The validity of sub- 
sequent pages is checked using the same method as lor a single page, except that the digest of the current pixmap 
is replaced by the digest of the concatenated previous signature and current pixmap. 

[0089] It will be appreciated that there are many ways of cryptographically chain'pig a subsequent page to a previous 
page. Such ways will be obvk>us to those skilled in the art of security in the light of the present descripiton. 
45 [0090) For added security, the image of each page of a multi-page document may be arranged to include the con- 
venttonal fooler 'Page x of y. where V is the number of the page and y Is the total nunrtber of pages. This enables 
ready detection by a person of a truncated document simply by reading the document. 

[0091] A significant benefit of the present document signing scheme is that a signed documenl can be ra«ighed and 
countersigned. As such, it is preferable for the surronary of a document to include an audit trail. There are many vari- 

so atkms on re-signing and countersigning, although (obvtously) an electronic integrity check should always be done 
before any further signing. At one extreme, the new signer oouW viewi confirm and re-sign each signed image in turn, 
effectively replacing the original signature by a new one. This method couM be used, for example, by a user signing 
a document prepared for him by someone else. At the other extreme, the new signer could simply *njbber stamp' the 
original signature by signing the original summary, without necessarily viewing the document at all. This couW be useful 

ss to a manager countersi^lng the wori( of a trusted employee. 

[0092] For a re-signing operation, the applicatton process 500 issues a re-signing request, and transmits an already 
signed document (plus the indivMual s'ignature(6) and the summary) to the trusted display processor 260. The tnisted 
display processor 260 verifies the signed documenl using the publk; key of the signei; recovers the pixnftaffof the 
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document (or each page of the document) and displays each verified image in the conect order to the new user, as if 
they were original images from the signature request applicatton. The user confirrris the acceptance of each individual 
Image, for example using a trusted switch 1 35 as before, and causes the images to'be signed as before by a smartcard 
belonging to the new user. This results in a signed document that is the same as the ortgtnal docunient except that it 

s has been signed by the smartcard belonging to the new user. 

[0093] Similarly, for a counter-signing operation, the application process 500 issues a counter-signing request and 
transmits the signed document (plus individual signatures and the summary) to the tnisted display processor 260. The 
trusted display processor 260 verifies the signed document and displays each verified image in the correct order to 
the new user, as if they were original images from the application process 500. The user confirms acceptance of each 

w individual image and the trusted display processor 260 signs the original summary using the smartcard belonging to 
the new user. Optionally the new user could provide a certificate of the previous user's public key. signed by the new i 
user, to ease the processing overhead associated with later verification of the signature. 

[0094] Clearly, there are many possible variations on the theme of re-signing and countersigning, which will be ap- 
parent to the skilled person in the fight of the present descriptkn. 

'5 [0095] Since a document may have a history of signing, re-signing and^or counter-signing, the present embodiment 
conveniently provides audit information, which fornis part of the document summary. This audit informatkx) allows the 
signature history o1 the document to be traced. The audK mformatton includes data about the prevkMis state of the 
document and the actions taken by the new user to create the new state of the document The audit informatton is 
signed by the trusted display processor 260. since the audit Informatnn must be independent of the usee The audit 

so information always contains any prevtous summary informalkin (including the si^iure on that summary information, 
by the previous signer). If the signed document has been created from scratch, the identity label Ipp of the trusted 
display processor 260 is inserted as an audit root. The audit informatkxi preferably also includes an indication of which 
indivkJual images were viewed and confirmed by the new user, and whether the document was created from scratch, 
or was re-signed, or was countersigned by the new user. To create a summaiy Including audit information, the smartcard 
is sent a digest of the audit inf ormatkxi concatenated with the previously described contents of a summary, rather than 
a digest of just the previously described contents of a summary. The rest of the process is as previously described. 
[0096] An enhancement to the proce& s for signing a document is that, prior to signing the pbemap data, the tnjsted 
display processor 260 compresses the pixmap using a k>ssles8 compresskxi algorithm so that the overiieads associ- 
ated with storing and sending the individual signature are reduced. 

so [0097] The pixmap may be compressed by standard compresston algorithms, for example a codeword-based algo- 
rithm applying L2-1 or 1.2-2 compression. Alternatively, a technique similar to OCR (optteal character recognitkm) may 
be used to compress the pixmap. In this case, the situation differs from conventional OCR in that the hput data has 
been perfectly 'scanned', albeit at a lower resolution than in conventional OCR The OCR-compressed verskm of the 
pixmap may be generated by 'btobmatching' to create an alphabet for the pbemap. constructing . a pbemap of each 

35 character in the alphabet, and constructing a message using those characters, such that the message represents the 
original pixmap. This means that the pamap can been compressed to a new alphabet and a message written in that 
alphabet. Since there are, obvk>usly. no errors nor. ambiguity in the pixmap data, this is a lossless compressbn method. 
[009q Another way of reducing the size of the image pixnriap is by representing the image as a pure black and white 
image, requiring only a single bit - set to zero or one - to define whether a pbcel is black or white. OthenMse. the 

49 document image Is represented as a full ootour image, where each pbcel may typk^lly require up to 24^. Obvk)U8ly. 
this technk^ue may be suitable for simple, black and white text-based documents. However, it wouM not be appropriate 
for cokxir documents or inlages. 

[0099] At any time, the document image may be converted back into a text-based docunrwnt using an OCR-type 
process to reconstruct a standard digital textual representatkxi of the document. This technique cannot be used in the 

4» signature, since the textual mapping may be incorrect, but can be used by the receiver of a signed docurnent toconvert 
it back into a standard digital textual representatkxi (such as ASCII) for subsequent machine manipulatkxi. In preferred 
embodiments, the trusted display processor 260 is equipped to enact OCR document recovery. 
[01 00] To enact OCR, an OCR alphabet is generated in a standard fashion and is then matched to stored fonts and 
hence converted to a standard character set. As in conventional OCR, ambiguous matches may be retained as a 

so pixmap and flagged for conversion by the user. (This is unlikely, particulariy if font type and size information has been 
supplied in the display format data FD, because there is no error in the data.) In cases of extreme cautkm. the entire 
reconstructed docurrient should be manually checked by a person against the view of the document that the signer 
intended to sign. 

[0101] Preferably all document reconstruction processes are done by processes that are trusted. 
ss [01 02] The preferred embodiment described at>ove relies on the premise that the trusted display processor 260 has 
direct and exclusive access to video data stored in the frame buffer memory 31 5, beyond the point where the video 
data can be manipulated by host computer 100 software, including the operating system. This implies that the vkJeo 
data cannot be modified unless the tnjsted display processor 260 makes the modificatk>n. 
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rOIOSI itwillbeappreciatedthatnotallcompuferarchrtecluresarearrangedinthisway. For example some computer 
KLures are anSnged such that the frame buffer memory fon«s a part of the rr^in m^^^ 

aS^s s^cMSA?) dlplay system. Or» benefit of such a system is that both |he CPU ar,d the cl-splay P~ 
Saccesstherame buffer memory and share the graphk* operation overhead, there^ 

5 Tnce Clearly, an implementation of the present invention in such a SAS system cannot rely on *>^J^^^ 
buffer rremory is safe during signing, since the CPU can still access the memory. However, there are many ways in 
which such a SAS system may be modified to support implementations of the present Bwentwi. For example the 
ZmJvZM be provided with a control line from a trusted display processor such that, donng a signing operaba^ 
ZZZ^s presented from being updated by data from the CPU. The '^^''^^^^fJJ^*'^ 

10 modified so that they include the extra logic to perfom. this funct«n. AfcematR^eV. ^"^^^^^"^^^J''*^^ 
other logic circuits inserted into the nomial control path of the memory. Such systems, therefore, re^r on the 
pIeL7thatthevideodatainfhef,amebuflermemorycanonlybemodified.otherthanbylhe trusted 
with the pemiission of the trusted display processor. Clearly, this premise Is as valid for secure opeiatnn as the first 

KrmpaTormeoperat«.gsWtemS.therebyrem«^^ 

CleU. in mis case, the graphics overhead put on the CPU will be higher than " asi«««« .T^JTS^lS^ 
processor hardware, thereby limiting the graphics perfom«nce of the platlom,. Clear^there '« ~ (J^^jJ^ 
^trusted display processor" as such. However. It will be apparent to the skilled person that the same lunclton as provided 
so by ,he trusted dteplay processor, that ol protecting the frame buffer memory and *"'«'^'"9 f™"?^.^^ 
irnplemented using an appropriate trusted component which controls the display system (m whatever fom.) dunng 

raioq' In other embodiments of the im^ention. in addition oraltematively. the tnisted display proceMor (oroqulvalenl) 
includes an interface for driving a trusted display. The trusted display might be. for example, an LCD panel display. In 

.» tho same way that the Inisted switch provides a trusted moans for a user to interact with the tmsted ^^'^P^VP'^'I^ 
the tnisted dteplay can provide a Uusted means for feeding back infomr«tion to the user other ^'^f^J^^ 
VOU. For example, the trusted display might be u««J to provide user status messag^. ^'^f/f ^J,^*^*,'"^ 
,o a signing operatton. As such, applications runolng on the standard host computer should "otbe aWe toa««» the 
trusted display, because the display is connected either directly to the tr^^^*^ *splay p««e.sor <'^«^*°'^ 

30 trusted channel. In essence, such a trusted display is an addition to the soK^lled Inisled interface desenb«l abow. 
in practice, there is no reason why other fom« of trusted feedback device, of wh«h the trusted d'sPteV* 
couldnotbeincludedlnaddHlon.ora8anaHemative. For example, there may be scenanoe where some form ol trusted 

sound device would be useful for piov'riing audble feedback. 



as 



Claims 

1. Adataprocessmgsystemarrangedtogeneiateadigitalslgnaturerepresentativeof adocument the data process- 
ing system comprising; 

JO 

main memory means for storing a documentto be digitally signed; ,„™„om.«n«.nhiefi 

main processing means for executing at least one applteation process corapnslng means to generate graphics 
signals for displaying the document; 

means tor generating a request signal lor the document to be signed; 
*5 a display system comprising: 

frame buffer memory; ......... .u- 

means lor geneiaUng digital image data representative of the document on the basis of the graphcs 
signals and storing the digiUl image data Bi the frame buffer memory; and 
so means lor reading the digital 'mage data from the frame buffer memory, converting the data nlo signate 

suitable for displaying an actual image thereof on a display means and f onwarding saM signals toa display 
means; and 

atru8tedcomponentcomprisingindopendentproce6singmeansoperable.inre8pon8etoreceiptoltherequM^ 
SS sigial. for generating a digital signature representative of the digital image data. 

2. A data processing system according to claim 1 . »«»erein the trusted component comprises means for denying to 
any unauthorised appOcation or process wrile access to at least the portion of the frame bu«er memory corrtainng 
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the digital image data of the document, and nneans for generating a digital signature representative of the digital 
image data while the respective portion of the frame buffer nriemory is not accessible tor writing data to. 

3. A data processing system according to claim 1 or claim 2. further comprising a removable token comprising 
i' processing means for receiving the digital image data, or a representation thereof, and generating a respective 

digital signature. 

4. A data processing system according to any one of the preceding claims, wherein the trusted component further 
comprises means for acquiring and/or generating trusted innage data and means for controlling the display system 

10 to highlight the displayed document irnage using the trusted image data 

5. A data processing system according to claim 4. wherein the trusted image data comprises pixmop data represent- 
ative of the trusted irnage or instructk)ri8 for forming the trusted irrage. 

io 6. A data processing system according to ciam 4 or claim 6. wherein the trusted component controls the display 
system to highlight the displayed document image by producing one or more of the followtng visual effects: 

a border, or an indicator or indicators defining a border, characterised by the tnjsted Innage and positioned at 
least partly around the document Image; 
20 a background pattern characterised by the trusted image forming at least part of the background of the doc- 

ument image; 

an image characterised by the trusted image formed within the document image; andf'or 

a text nnessage characterised by the trusted image formed within or near the document image. 

25 7. A data processing system according to any ono of claims 4 to 6, wherein tfio trusted component comprises moans 
for acquiring and/or generating trusted image data from a removable token. 

8. A data processing system according to any one of the preceding claims, wherein the trusted component further 
comprises means for controlling the display system to display messages to a user. 

9. A data processing system aocprding to claim 8. further comprising trusted input means by which a user can respond 
to messages in a secure fashkan. 

10. A data processing system according to claim 9. wherein the trusted input nfieans comprises a switch connected 
3S to the trusted component via a secure communk:ations channel. 

11. A data processing system according to dalm 3 or claim 7, wherein the trusted component and the secure token 
enact a mutual authentteatron process in advance of further interactkxjs. 

4C* 12. A data processing system according to any one of the preceding claims, wherein the trusted component forms an 
integral part of the display system. 

13. A data processing system according to daim 12, wherein the display system Is arranged such that the trusted 
component is physically and functk)nally posilksned between the main processing means and the frame buffer 

45 memory, such that the main processing means can only access the frame buffer memory indirectly through func- 
tions of the trusted component. 

14. A data processing system according to any one of the preceding claims, further comprising means for geneiating 
data summarising a digital signature operation. 



30 



so 



15. A method for digitally signing a document, comprising the steps: 



generating digital image data of the document and updating the digital innage data in a frame buffer n>emory; 
reading the digital image data from the frame buffer memory, converting the digital image data into signals 
ss suitable for driving a visual display means and transmitting the signals to a visual display means for displaying 

an image of the document; and 

on demand, reading the digital image data from the frame buffer memory and generating a digital signature 
representative thereof. 
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A method according to claim 1 6. further comprising the step of temporarily denying write access to the frame buffer 
memory by unauthorised processes while generating the digital signature. 

A method according to claim 14 or claim 15. further comprising the step of acquiring and/or generating trusted 
image data and using the trusted Innage data to highlight the document image. 

A method according to claim 17, wherein step of highlighting the document image Is achieved by generating any 
one or more of the following visual effects: 

a border, or an indicator or indicators defining a border, characterised by the trusted image and positioned at 
least partly around the document image; , 
a background pattem characterised by the trusted image forming at least part d the background of the doc- 
ument image; 

an image characterised by the taisted image formed within the document inriage; andtor 
a text message characterised by the trusted image formed within or near the document image. 

A method according to claim 17 or claim 18. wherein the tnisied image data is acquired from a removable token. 

A data processing system arranged to digitally sign a document In accordance with any one of claims 1 5 to 1 9. 

A method for digitally signing a document comprising a plurality of individual viewable pages, comprising the steps: 

a) generating digital image data of the first page ol the document and updating the digital image data in a 
frame buffer memory; 

SB b) reading the digital image data from the frame buffer monrwry. converting the digital image data into signals 

suitable for driving a visual display means and transmitting the signals to a visual display means for displaying 
an image of the document; 

c) reading the digital image data from the frame buffer memory, generating a digital signature representative 
thereof and storing the digital signature; 
30 iv) repeating steps a) to c) for the other page(s) of the document; and 

V) generating a further digital signature representative of all previous digital signatures. 

22. A method for a second user to digitally counter-sign a document that has already been signed by a first user, the 
document being accompanied by a respective first digital signature generated by using a secret of the first usei; 

^ comprising the steps: 

generating digital image data of the document and updating the digital image data in a frame buffer memory; 
reading the digital image data from the frame buffer menwry, convening the digital image data into signals 
suitable lor driving a visual display nrmns and transmitting the signals to a visual displ^ means for displaying 
<o an image of the document; 

verifying the integrity of the first digital signature; and 

on the basis of a secret of the second user, generating a digital signature representative of the first digital 

signature. 

23. A method lor a second user to digitally resigning a document that has already been signed by a first user, the 
document being accompanied by a respective first digital signature generated by using a secret of the firet user, 
comprising the steps: 

generating digital image data of the document and updating the digital image data in a frame buffer memory; 
so reading the digital image data from the frame buffer mennory. converting the digital image data into signals 

suitable for driving a visual display nraeans and transmitting the signals to a visual display means for displaying 
an image of the document; 

verifying the integrity of the first digital signature; and 

reading the digital image data from the frame buffer menwry and, on the basts of a secret of the second user, 
ss generating a digital signature representative of the first digital signature. 

24. A data processing system arranged to generate a digital signature representative of a document, the data process- 
ing system comprising; 
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mafn processing means for generating graphics signals (or displaying a 
a display system comprising: 

frame buffer memory; 

means for generating digital image data representative of the document on the basis of the graphics 
signals and storing the digital image data in the f rarrie buffer memory: and 

means for reading the digital image data from the frame buffer menriory, converting the data into signals 
suitable for displaying an actual image thereof on a display means and forwarding said signals to a display 
means; and 

means for generating a digital signature representative of the digital image data. 

25. A system for digitally signing a document comprising 

'5 frame buffer memory; 

nneans for generating In^ge data representative of a document and storing the image data in the frame buffer 
memory; 

means lor reading the image data from the frame buffer memory and displaying a respective image on a 
display means; and 

^0 means for reading the image data from the frame buffer memory and generating a digital signature thereof. 

26. A tnisted component tor use in a data processing system according to any one of claims 1 to 14. 

27. A tnisted component according to clatm 26, fabricated to be tannper resistant 
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